home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-moore-mime-delivery-00.txt < prev    next >
Encoding:
Text File  |  1993-09-17  |  16.0 KB  |  488 lines
  1. Network Working Group                                        Keith Moore
  2. Internet Draft                                   University of Tennessee
  3.                                                        16 September 1993
  4.  
  5.  
  6.                            MIME Content-Types
  7.                    For Delivery Status Notifications
  8.  
  9.                     draft-moore-mime-delivery-00.txt
  10.  
  11.  
  12. 1. Status of this Memo
  13.  
  14.    This document is an Internet Draft.  Internet Drafts are working
  15. documents of the Internet Engineering Task Force (IETF), its Areas, and
  16. its Working Groups.  Note that other groups may also distribute working
  17. documents as Internet Drafts.
  18.  
  19.    Internet Drafts are valid for a maximum of six months and may be
  20. updated, replaced, or obsoleted by other documents at any time.  (The
  21. file 1id-abstracts.txt, available via anonymous ftp from nic.ddn.mil,
  22. describes the current status of each Internet Draft.)  It is not
  23. appropriate to use Internet Drafts as reference material or to cite them
  24. other than as "work in progress".
  25.  
  26.  
  27. 2. Abstract
  28.  
  29.    This memo defines a message format which may be used by a message
  30. transfer agent (MTA) or internetwork mail gateway to report the result
  31. of an attempt to deliver a message to one or more recipients.  The
  32. message format utilizies several MIME content-types which are also
  33. defined by this memo.
  34.  
  35.  
  36. 3. Introduction
  37.  
  38.    The SMTP protocol [1] requires that an SMTP server provide
  39. notification of delivery failure, if it determines that a message cannot
  40. be delivered to one or more recipients.  Traditionally, such
  41. notification consists of an ordinary Internet mail message (in the
  42. format defined by [2]), sent to the envelope sender address (supplied
  43. with the SMTP MAIL command), containing a human-readable explanation of
  44. the error, and at least the headers of the failed message.
  45.  
  46.    Experiences with large mail distribution lists [3] indicates that
  47. such messages are often insufficient to diagnose problems, or even to
  48. determine at which host or for which recipients a problem occurred.  In
  49. addition, the lack of a standardized format for delivery notifications
  50. in Internet mail makes it difficult to exchange such notifications with
  51. other message handling systems.
  52.  
  53.    This memo defines a MIME [4] based protocol for delivery status
  54. notifications (DSNs) in Internet mail.  This protocol can be used to
  55. notify the sender of a message of any of several conditions: successful
  56.  
  57.  
  58.  
  59. K. Moore                  Expires 16 March 1994                 [Page 1]
  60.  
  61.  
  62. Delivery Status Notifications                          16 September 1993
  63.  
  64.  
  65.  
  66. delivery, failed delivery, message forwarding, or the gatewaying of a
  67. message into an environment that may not support DSNs.
  68.  
  69.    NOTE:  A Delivery Status Notification (DSN) is different from a
  70. Receipt Notification (RN).  A DSN is issued by the mail transport
  71. system, and indicates whether a message was successfully delivered to a
  72. recipient's mailbox.  A DSN conveys no information about what happens to
  73. the message after it has reached the mailbox.  An RN is issued by a
  74. recipient's mail reader or message store, and conveys information about
  75. whether a message has been read by the recipient.
  76.  
  77.    This memo defines the format of a DSN.  An extension to the SMTP
  78. protocol to request DSNs is the subject of another memo [5].  Neither of
  79. these protocols support receipt notifications.  As of this writing,
  80. protocols for RNs and requests-for-RNs is are yet to be defined.
  81.  
  82.  
  83. 4.  The multipart/delivery-status-notification MIME content-type
  84.  
  85.    The multipart/delivery-status-notification content-type is defined as
  86. follows:
  87.  
  88.       MIME type name: multipart
  89.       MIME subtype name: delivery-status-notification
  90.       Required parameters: same as in multipart/mixed
  91.       Optional parameters: none
  92.       Encoding considerations: same as in multipart/mixed
  93.       Security considerations: see section 7 of this memo.
  94.  
  95.    The multipart/delivery-status-notification content-type is to be used
  96. as the top-level content type for any DSN.  This content-type up to
  97. three sub-parts, in the following order:
  98.  
  99. (1) [required]  A text/plain body part containing explanatory text.
  100.     This text may be in any MIME-standard charset.
  101.  
  102. (2) [required]  A message/delivery-report body part containing the
  103.     details of the failed or successful delivery.
  104.  
  105. (3) [optional]  A message/rfc822-fragment body part containing the
  106.     returned contents.
  107.  
  108.    If the "returned contents" body part is present, a Content-ID header
  109. should be associated with this body part, and the "returned-content"
  110. parameter of the message/delivery-report body part should indicate the
  111. content-id of the returned contents.
  112.  
  113.  
  114.  
  115.  
  116.  
  117.  
  118.  
  119.  
  120. K. Moore                  Expires 16 March 1994                 [Page 2]
  121.  
  122.  
  123. Delivery Status Notifications                          16 September 1993
  124.  
  125.  
  126.  
  127. 5.  The message/delivery-report MIME content-type
  128.  
  129.    The message/delivery-report content-type is defined as follows:
  130.  
  131.       MIME type name: message
  132.       MIME subtype name: delivery-report
  133.       Required parameters: none
  134.       Optional parameters: id, returned-content, charset
  135.       Encoding considerations: Any content-transfer-encoding may be
  136.                                used.  7BIT is recommended unless an
  137.                                alternate charset is required; otherwise,
  138.                                use an appropriate encoding for that
  139.                                charset.
  140.       Security considerations: discussed in section 7 of this memo.
  141.  
  142.    The "id" parameter contains the envelope message-id of the message
  143. for which the report is being generated (which may or may not be the
  144. same as the message-id header).
  145.  
  146.    If the message containing the delivery-report contains the returned
  147. message, the "returned-content" parameter specifies the MIME content-id
  148. of that message.  If no "returned-content" parameter is supplied, the
  149. content is not returned.
  150.  
  151.    The "charset" parameter is optional.  If it appears, it applies only
  152. to the "text" fields of the delivery-report, and only if these fields
  153. are written using the "alternate charset" mechanism defined by STIF.  At
  154. any rate, such charsets must be registered for use with the MIME
  155. "text/plain" body part type.
  156.  
  157.    The body of the delivery-report consists of one or more (per-
  158. recipient) records formatted according to STIF [6].  Each record
  159. consists of the following fields:
  160.  
  161. orig-rcpt The Internet mail address of the recipient, as originally
  162.           specified by the sender.  [optional]
  163.  
  164. rcpt      The electronic mail address of the recipient, from the message
  165.           envelope presented to the MTA or gateway issuing the report.
  166.           [required if orig-rcpt is not present]
  167.  
  168. mta       The Internet domain name of the MTA or gateway generating the
  169.           report.  For MTAs and gateways not on the Internet, a unique
  170.           name that reflects the location of the MTA or gateway may be
  171.           used. [required]
  172.  
  173. date      The date of the delivery attempt, in RFC 822 "date-time"
  174.           format.  [required for "delivered", "relayed", or "forwarded"
  175.           reports, optional for "failed" reports]
  176.  
  177.  
  178.  
  179.  
  180.  
  181. K. Moore                  Expires 16 March 1994                 [Page 3]
  182.  
  183.  
  184. Delivery Status Notifications                          16 September 1993
  185.  
  186.  
  187.  
  188. action    One of "delivered", "failed", "relayed", or "forwarded".
  189.           [required]
  190.  
  191.           An action value of "delivered" indicates that the message has
  192.           been successfully delivered to the recipient address specified
  193.           by the sender.  (This includes "delivery" to a distribution
  194.           list expander.)
  195.  
  196.           A value of "failed" indicates that the message could not be
  197.           delivered to the recipient.
  198.  
  199.           A value of "relayed" indicates that the message has been
  200.           relayed or gatewayed into an environment that does not
  201.           accepted responsibility for generating delivery reports that
  202.           conform to this specification.
  203.  
  204.           A value of "forwarded" indicates that the message has been
  205.           delivered to the recipient address as specified by the sender,
  206.           and forwarded beyond that destination to one or more
  207.           additional addresses.
  208.  
  209.           The keywords "delivered", "failed", "relayed", and "forwarded"
  210.           may be spelled in any combination of upper and lower case
  211.           characters.
  212.  
  213. status    A 3-digit SMTP reply-code, indicating the delivery status for
  214.           that recipient.  Normally this will be the reply-code returned
  215.           by an SMTP server in response to a RCPT command.  Reply-codes
  216.           are defined in [1], [5], [7], [8], and other SMTP service
  217.           extension documents.  If none of these reply codes is
  218.           appropriate, any of "200", "400", or "500" may be used to
  219.           indicate success, "temporary" failure, or "permanent" failure,
  220.           respectively.  [optional]
  221.  
  222. text      Text describing the error.  This field ONLY may be in the
  223.           character set specified by the "charset" parameter of the body
  224.           part, if it is written using the "alternate charset" mechanism
  225.           of STIF.  If the alternate charset mechanism is not used, or
  226.           if the charset parameter does not appear, the text must be in
  227.           US-ASCII. [optional]
  228.  
  229. tag       Additional information which may be used by internetwork mail
  230.           gateways to allow mapping of DSNs to and from similar services
  231.           in other environments.  The contents of the tag are defined by
  232.           the protocol used to request delivery reports.  [optional]
  233.  
  234.  
  235. 6. Conformance and Usage Requirements
  236.  
  237.    An MTA or gateway conforms to this specification if it generates DSNs
  238. according to the format defined here.  For MTAs and gateways that do not
  239.  
  240.  
  241.  
  242. K. Moore                  Expires 16 March 1994                 [Page 4]
  243.  
  244.  
  245. Delivery Status Notifications                          16 September 1993
  246.  
  247.  
  248.  
  249. support requests for delivery notification (such as in [5]), it is
  250. sufficient that delivery failure reports use this format.
  251.  
  252.    An MTA or gateway should NOT generate "delivered", "relayed", or
  253. "forwarded" DSNs unless specifically requested by the sender, via the
  254. SMTP extension defined in [5] or some other MTA-level protocol.
  255.  
  256.    MTAs and gateways should not use the "orig-rcpt" field of the
  257. message/delivery-report content-type unless the mail transfer protocol
  258. ensures that the address provided is that originally specified by the
  259. sender of the message.  (Ordinary SMTP does not make that guarantee; the
  260. SMTP extension defined in [5] does.)
  261.  
  262.    DSNs must be returned to the sender of the message, in such a way
  263. that the notification itself will not "bounce" if delivery of the
  264. notification fails.  (In SMTP, this is accomplished by using an empty
  265. string as the sender address in the MAIL command.)
  266.  
  267.    This specification places no restrictions on the use of delivery
  268. notifications by recipient user agents or distribution lists.
  269.  
  270.  
  271. 7. The message/rfc822-fragment content-type
  272.  
  273.    The message/rfc822-fragment content-type is defined as follows:
  274.       MIME type name: message
  275.       MIME subtype name: rfc822-fragment
  276.       Required parameters: none
  277.       Optional parameters: none
  278.       Encoding considerations: any standard MIME content-transfer-
  279.                                encoding may be used.
  280.       Security considerations: none
  281.  
  282.    A message returned in a DSN may have been truncated for any of
  283. several reasons.  If such a message were packaged in a message/rfc822
  284. content-type, a missing final boundary marker might confuse MIME mail
  285. readers.
  286.  
  287.    The message/rfc822-fragment content-type is used to label an RFC 822
  288. (or MIME) message which may not be complete.  Unlike a message/rfc822
  289. content-type, the message/rfc822-fragment content-type is opaque to the
  290. mail system.  In general, mail handling software should not assume that
  291. such a body part is well-formed according to either RFC 822 or MIME.
  292.  
  293.    Gateways are specifically prohibiting from "taking apart" and
  294. translating a message/rfc822-fragment message and performing operations
  295. on its component parts.  When necessary, a gateway may apply a content-
  296. transfer-encoding to the entire contents of an unencoded
  297. message/rfc822-fragment body part, but it must not attempt to perform
  298. such transformations on the individual components of the body part.
  299.  
  300.  
  301.  
  302.  
  303. K. Moore                  Expires 16 March 1994                 [Page 5]
  304.  
  305.  
  306. Delivery Status Notifications                          16 September 1993
  307.  
  308.  
  309.  
  310.  8. Security considerations
  311.  
  312.    Delivery notifications may be forged as easily as ordinary Internet
  313. electronic mail.  User agents and automatic mail handling facilities
  314. (such as mail distribution list expanders) that wish to make use of such
  315. notifications, should take appropriate precautions to minimize the
  316. potential damage from denial-of-service attacks.
  317.  
  318.  
  319. 9. References
  320.  
  321.  
  322. [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
  323.     USC/Information Sciences Institute, August 1982.
  324.  
  325. [2] Crocker, D., "Standard for the Format of ARPA Internet Text
  326.     Messages", STD 11, RFC 822, UDEL, August 1982.
  327.  
  328. [3] Westine, A., Postel, J. "Problems with the Maintenance of Large
  329.     Mailing Lists.", RFC 1211, USC/Information Sciences Institute, March
  330.     1991.
  331.  
  332. [4] Borenstein, N., Freed, N. "Multipurpose Internet Mail Extensions",
  333.     RFC 1341, Bellcore, Innosoft, June 1992.
  334.  
  335. [5] Moore, K.  "SMTP Service Extension for Delivery Reports", Internet
  336.     Draft "draft-moore-smtp-drpt-00.txt", 16 September 1993.
  337.  
  338. [6] Crocker, D.  "Structured Text Information Format (STIF)", Internet-
  339.     Draft "draft-crocker-stif-00.txt", June 1993.
  340.  
  341. [7] Klensin, J., Freed, N., Rose, M., Stefferud, E., Crocker. D.  "SMTP
  342.     Service Extensions." RFC 1425, United Nations University, Innosoft
  343.     International, Inc., Dover Beach Consulting, Inc., Network
  344.     Management Associates, Inc., The Branch Office, February 1993.
  345.  
  346. [8] Klensin, J., Freed, N., Moore, K.  "SMTP Service Extension for
  347.     Message Size Declaration."  RFC 1427, United Nations University,
  348.     Innosoft International, Inc., University of Tennessee, February
  349.     1993.
  350.  
  351.  
  352.  
  353.  
  354.  
  355.  
  356.  
  357.  
  358.  
  359.  
  360.  
  361.  
  362.  
  363.  
  364. K. Moore                  Expires 16 March 1994                 [Page 6]
  365.  
  366.  
  367. Delivery Status Notifications                          16 September 1993
  368.  
  369.  
  370.  
  371. 10. Author's address
  372.  
  373. Keith Moore
  374. University of Tennessee
  375. 107 Ayres Hall
  376. Knoxville, TN 37996-1301
  377. USA
  378.  
  379. email: moore@cs.utk.edu
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394.  
  395.  
  396.  
  397.  
  398.  
  399.  
  400.  
  401.  
  402.  
  403.  
  404.  
  405.  
  406.  
  407.  
  408.  
  409.  
  410.  
  411.  
  412.  
  413.  
  414.  
  415.  
  416.  
  417.  
  418.  
  419.  
  420.  
  421.  
  422.  
  423.  
  424.  
  425. K. Moore                  Expires 16 March 1994                 [Page 7]
  426.  
  427.  
  428. Delivery Status Notifications                          16 September 1993
  429.  
  430.  
  431.  
  432. Appendix: Example delivery notification
  433.  
  434.  
  435. From: postmaster@netlib2.cs.utk.edu
  436. To: j.random.user@cs.utk.edu
  437. Subject: delivery notification
  438. Content-type: multipart/delivery-notification; boundary=xyzzy
  439. MIME-Version: 1.0
  440.  
  441. --xyzzy
  442. Content-type: text/plain; charset=us-ascii
  443.  
  444. Your mail message could not be delivered to some of the recipients
  445. listed below.  The message has been returned to you.
  446.  
  447. --xyzzy
  448. Content-type: message/delivery-report;
  449.  id="<930624.AA09834@cs.utk.edu>";
  450.  returned-content="<0xffcc8090@netlib2.cs.utk.edu>"
  451.  
  452. < orig-rcpt: bogus.user@netlib2.cs.utk.edu; status: 550;
  453.   by: netlib2.cs.utk.edu; date: Thu, 24 Jun 1993 18:43:03 -0400;
  454.   action: failed; text: <bogus.user@cs.utk.edu>: no such user; >
  455. < orig-rcpt: remote.user@netlib2.cs.utk.edu; by: netlib2.cs.utk.edu;
  456.   date: Thu, 24 Jun 1993 18:43:04 -0400; action: relayed;
  457.   text: next-hop MTA does not support delivery reports;>
  458. < orig-rcpt: big-mailing-list@netlib2.cs.utk.edu; by: netlib2.cs.utk.edu;
  459.   date: Thu, 24 Jun 1993 18:43:07 -0400; action: delivered;
  460.   text: message sent to list recipients;>
  461. < orig-rcpt: moore@netlib2.cs.utk.edu;  by: netlib2.cs.utk.edu;
  462.   date: Thu, 24 Jun 1993 18:43:07 -0400; action: forwarded;
  463.   text: message forwarded to <moore@cs.utk.edu>;>
  464.  
  465. --xyzzy
  466. MIME-Version: 1.0
  467. Content-type: message/rfc822
  468. Content-id: <0xffcc8090@netlib2.cs.utk.edu>
  469.  
  470. Received: by netlib2.cs.utk.edu; Thu, 24 Jun 1993 18:43:03 -0400
  471. To: bogus.user@netlib2.cs.utk.edu, remote.user@netlib2.cs.utk.edu,
  472.  big-mailing-list@netlib2.cs.utk.edu, moore@netlib2.cs.utk.edu
  473. From: j.random.user@cs.utk.edu
  474. Date: Thu, 24 Jun 1993 18:42:09 -0400
  475. Subject: quote
  476. Message-id: <930624.AA09834@cs.utk.edu>
  477.  
  478.  
  479. "Don't sweat it -- it's not real life.  It's only ones and zeroes."
  480.                  -- spaf
  481.  
  482. --xyzzy--
  483.  
  484.  
  485.  
  486. K. Moore                  Expires 16 March 1994                 [Page 8]
  487.  
  488.